Weak Entity Types
In this lesson, we will look at the last component of our ER model.
We'll cover the following
Weak entity types#
Entity types that do not have key attributes of their own are called weak entity types like the DEPENDENT entity type in the company database.
In contrast, regular entity types that do have a key attribute are called strong entity types. Entities belonging to a weak entity type are identified by being related to specific entities from another entity type in combination with one of their attribute values. We call this other entity type the identifying or owner entity type, and we call the relationship type that relates a weak entity type to its owner the identifying relationship of the weak entity type.
Consider the entity type DEPENDENT, related to EMPLOYEE, which is used to keep track of the dependents of each employee via a 1:N relationship. In the diagram below, the attributes of DEPENDENT are Name, Birth_Date, and Relationship (to the employee). Two dependents of two distinct employees may, by chance, have the same values for Name, Birth_Date, and
Relationship, but they are still distinct entities. They are identified as distinct entities only after determining the particular EMPLOYEE entity to which each dependent is
related.
In ER diagrams, both a weak entity type and its identifying relationship are distinguished by surrounding their boxes and diamonds with double lines.
We also notice that a weak entity type normally has a partial key, which is the attribute that can uniquely identify weak entities that are related to the same owner entity. In our example, if we assume that no two dependents of the same employee ever have the same first name, the attribute Name of DEPENDENT is the partial key. In the ER diagram above, the partial key attribute is underlined with a dashed or dotted line.
Furthermore, a weak entity type always has a total participation constraint (existence dependency) with respect to its identifying relationship because a weak entity cannot be identified without an owner entity.
The next lesson will include an exercise where you will design an ER diagram for a university database.
